<html>
<head><meta charset="utf-8"><title>performance · project-safe-transmute · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/index.html">project-safe-transmute</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html">performance</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="183071224"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183071224" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183071224">(Dec 10 2019 at 15:40)</a>:</h4>
<p>One of the <a href="https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431/9?u=rylev" target="_blank" title="https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431/9?u=rylev">concerns</a> with the current proposal is that it will not be performant enough for many use cases and thus people will be forced to resort back to unsafe transmute instead. </p>
<p>It does seem like in a large amount of cases the compiler is sufficiently smart enough to boil away the runtime checks through constant folding since most of the checks are <code>const</code>. For example, <a href="https://godbolt.org/z/AYjBnD" target="_blank" title="https://godbolt.org/z/AYjBnD">the compiler is able to boil away all runtime checks</a> between two types that are not trivially related (i.e., transmuting works only because they happen to share the same layout). There is at least <a href="https://godbolt.org/z/xYrPGJ" target="_blank" title="https://godbolt.org/z/xYrPGJ">one case</a> however where not all runtime checks are eliminated despite there actually being no need for them. </p>
<p>Given this, there might be sufficient reason to reject the current proposal. Not only does the user often have to deal with unwrapping results from casting where it's obvious that the cast cannot fail, but also the compiler cannot always guarantee that unnecessary runtime checks are eliminated. Thoughts and/or questions?</p>



<a name="183073175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183073175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183073175">(Dec 10 2019 at 16:01)</a>:</h4>
<p>This doesn't worry me very much. I'd be curious to see numbers.</p>
<p>Reasons that it doesn't worry me:</p>
<ul>
<li>I think that there will be many times when there is no runtime hit</li>
<li>I think that there are many, many applications where the runtime hit will be acceptable</li>
<li>I imagine we could offer an "unsafe" extension, where you can use this API most of the time, and sometimes add a bit of unsafe code as a tweak in particular hot spots, and it still offers you more structure than a plain transmute</li>
</ul>
<p>However, it seems like the first two arguments are ones that are best made with experience and examples.</p>
<p>I guess I also hope that we will be able to grow the language to address things like the UB  that can result from uninitialized memory and padding, which I imagine is responsible for a lot of the cases where this API would "almost" apply but doesn't quite (is that inaccurate?).</p>



<a name="183073853"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183073853" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183073853">(Dec 10 2019 at 16:07)</a>:</h4>
<p>The counter argument to that is that if performance is not of utmost concern to you, why not just copy? I would imagine that those who want to use this API would like for it to have the same runtime characteristics as <code>std::mem::transmute</code> with the addition of runtime checks when those checks would be necessary in the unsafe code. I think this is a perfect example of a "zero-cost abstraction". Ideally there would be no better way to write this by hand using <code>std::mem::transmute</code>. There is definitely a way for us to have an API that does not require runtime checks unless completely necessary. The only question is can we make it nice to use. </p>
<p>The pre-RFC in its current form doesn't really _directly_ address uninitialized memory or padding, it just ensures that the user does not accidentally transmute to or from memory that would cause UB.</p>



<a name="183075860"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183075860" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183075860">(Dec 10 2019 at 16:29)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> I guess it depends on the scope too =)</p>
<p>I'm assuming that there might be something like <code>Vec&lt;T&gt; =&gt; Vec&lt;U&gt;</code> conversions, which seems very powerful</p>



<a name="183096777"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183096777" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183096777">(Dec 10 2019 at 20:06)</a>:</h4>
<p>It's both powerful and also fairly easy. Crates already exist that can do it (though I cannot guarantee they do it with 0 overhead).</p>



<a name="183100382"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183100382" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Yato <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183100382">(Dec 10 2019 at 20:45)</a>:</h4>
<p>My crate vec-utils maps from <code>Vec&lt;T0&gt;</code>, <code>Vec&lt;T1&gt;</code>, <code>Vec&lt;T2&gt;</code>, ... to <code>Vec&lt;U&gt;</code> (when given a mapping function) which reuses the largest valid allocation and also provides the functionality to reuse the allocation of a <code>Vec</code> with 0 extra cost (sound <code>Vec</code> transmute).</p>



<a name="183100407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183100407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183100407">(Dec 10 2019 at 20:45)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> In the godbolt you linked, <code>example</code> and <code>beispiel</code> are identical. If you simply replace the body of <code>example2</code> and <code>beispiel2</code> with calls to <code>example</code> and <code>beispiel</code> then the "2" functions will also end up with identical code. You can also remove a jump from the <code>example2</code> that you posted by replacing the <code>panic!("This can't happen")</code> with <code>unreachable!</code>.</p>
<p>Basically the optimizer is (and always will be) a quirky beast, but I don't think that means that the design itself has any inherent flaws.</p>



<a name="183119792"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183119792" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183119792">(Dec 11 2019 at 01:26)</a>:</h4>
<blockquote>
<p>There is at least <a href="https://godbolt.org/z/xYrPGJ" target="_blank" title="https://godbolt.org/z/xYrPGJ">one case</a> however where not all runtime checks are eliminated despite there actually being no need for them. </p>
</blockquote>
<p>In this case, the only runtime check that isn't eliminated is the check to see if the value is <code>&gt; 1</code>.  This happens because rustc only communicates the <code>&lt;= 1</code> assumption to LLVM when <em>loading</em> from a bool-typed reference, whereas in your example the load doesn't happen until after the conversion.</p>



<a name="183119826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183119826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183119826">(Dec 11 2019 at 01:27)</a>:</h4>
<p>But that seems like an edge case.  The only time that the <code>&gt; 1</code> check would be redundant is when converting from <code>bool</code> to <code>bool</code>, as in your example, but (a) that's useless, (b) to handle situations where it might come up in generic code, the standard library could add a specialization to skip the checks when the source and target types are the same.</p>



<a name="183120013"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183120013" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183120013">(Dec 11 2019 at 01:31)</a>:</h4>
<p>That said, I also think that the idea of an overridable trait method that validates the slice data (i.e. <code>from_bytes</code>) is not super useful as a whole.  What is it useful for other than <code>&amp;[bool]</code>?</p>



<a name="183139126"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183139126" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183139126">(Dec 11 2019 at 09:16)</a>:</h4>
<p>The case where source and target type have the same invariants <em>does</em> matter. It doesn't only happen when the types are identical (which is indeed a corner case and can be optimized transparently by specialization) but also whenever newtypes are involved. Being able to safely type-pun in those cases without performance overhead would be a great enabler for more type-safe abstractions (vs the status quo of needing to copy potentially large amounts of memory or needing <code>unsafe</code>). And libstd can't specialize those cases to skip validation as they involve downstream types and user-defined invariants.</p>
<p>Taking this consideration to the logical extreme probably leads to a design where "validate whether these bytes are OK for that type" is not the central operation (maybe one that happens occasionally at system boundaries). I'm not saying such a design should be adopted (don't have to solve every use case at once) but there are use cases for such conversions.</p>



<a name="183142417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183142417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183142417">(Dec 11 2019 at 10:07)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> <span class="user-mention" data-user-id="198590">@comex</span> I don't believe this is an edge case. This also applies to other conversions (e.g., numbers to c-style enums). I will spend some more time thinking of examples to look over. In any case, given the performance oriented nature of this feature, I think it's important that we try to eliminate performance foot-guns. The code as it reads right now does not make it obvious that runtime checks will not be performed in many cases _and_ it certainly does not make it obvious where the compiler can eliminate all runtime checks and where it cannot. Ideally <code>bool_new_type.cast::&lt;bool&gt;()</code> would not return a <code>Result</code> and would be guaranteed to not perform any runtime checks.</p>



<a name="183143711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183143711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183143711">(Dec 11 2019 at 10:27)</a>:</h4>
<p>For posterity here's a non-trivial example of Rust doing the right thing with regards to eliminating unnecessary runtime checks (only bool is checked when it has to be): <a href="https://godbolt.org/z/4M3dGp" target="_blank" title="https://godbolt.org/z/4M3dGp">https://godbolt.org/z/4M3dGp</a></p>



<a name="183144203"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183144203" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183144203">(Dec 11 2019 at 10:34)</a>:</h4>
<p>And here's an example where two structs are structurally identical to each other and should therefore be directly transmutable to and from each other but Rust is not smart enough to see that and so it inserts unnecessary runtime checks: <a href="https://godbolt.org/z/evPTtK" target="_blank" title="https://godbolt.org/z/evPTtK">https://godbolt.org/z/evPTtK</a></p>



<a name="183144651"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183144651" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183144651">(Dec 11 2019 at 10:41)</a>:</h4>
<blockquote>
<p>For posterity here's a non-trivial example of Rust doing the right thing with regards to eliminating unnecessary runtime checks (only bool is checked when it has to be): <a href="https://godbolt.org/z/4M3dGp" target="_blank" title="https://godbolt.org/z/4M3dGp">https://godbolt.org/z/4M3dGp</a></p>
</blockquote>
<p>I'm not sure what this example is supposed to illustrate. The B -&gt; A direction goes through a <em>manual</em> impl that does nothing but check the bool (so there's nothing to optimize out in those examples), while the B -&gt; A direction only has size and align checks to optimize out and it's not news that those can be optimized out very well. The more interesting case would be if (1) B also had a bool field in the same place, and (2) the impls were more mechanical, closer to how they would actually be generated by rustc/derives. In particular note that the <code>impl FromBytes for A</code> is missing size and alignment checks and hard-codes the knowledge that fields <code>a</code> and <code>c</code> are <code>FromAnyBytes</code>.</p>



<a name="183147668"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183147668" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183147668">(Dec 11 2019 at 11:23)</a>:</h4>
<p>It was just meant to be the same example as we’ve seen before just in a non-trivial case to show that the compiler can easily see through aggregate types. If that’s obvious to you than there’s no need to look at it.</p>



<a name="183147704"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183147704" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183147704">(Dec 11 2019 at 11:23)</a>:</h4>
<p>I’ll fix the second example. I don’t expect it to change anything.</p>



<a name="183147757"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183147757" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183147757">(Dec 11 2019 at 11:24)</a>:</h4>
<p><span class="user-mention" data-user-id="124289">@rkruppe</span> can you explain what you mean by “more mechanical “?</p>



<a name="183148375"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183148375" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183148375">(Dec 11 2019 at 11:33)</a>:</h4>
<p>I would expect from the pre-RFCs that the impls for aggregates that require some validation would be auto-generated by straight-forwardly composing calls to validate each field in turn. The impl in your example, on the other hand, looks like a lot of thought was put into identifying the least amount of work to do, from only considering some fields to manually computing the offset of each field to inlining the validity check for it. Even if some compiler magic is used to ensure e.g. absence of padding for <code>ToBytes</code> types, I don't think we should work under the assumption that the generation of the trait impls happens late enough in the compiler to be able to modify its behavior based on e.g. whether field types are <code>FromAnyBytes</code> or use layout computation results.</p>



<a name="183152115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183152115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183152115">(Dec 11 2019 at 12:36)</a>:</h4>
<p>I believe that's a limitation of the current proposal that was meant to be addressed by <a href="https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431/2" target="_blank" title="https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431/2">what Josh posted</a> (and what you, <span class="user-mention" data-user-id="124289">@rkruppe</span> helped with I believe). Without that addendum, I believe each <code>from_bytes</code> implementation would need to be generated separately. How that would be done is not specified in the proposal so far. This add more support for the need for a separate validation function IMO.</p>



<a name="183156329"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183156329" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183156329">(Dec 11 2019 at 13:31)</a>:</h4>
<p>FWIW I think it would be interesting to see if just doing the conversion for each field and checking if it succeeds (like the first option in Josh's post) does optimize well. But separate validation has other advantages so maybe it's not worth the trouble.</p>



<a name="183157198"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183157198" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183157198">(Dec 11 2019 at 13:41)</a>:</h4>
<p>The example I posted above is incorrect because the <code>A</code> struct has padding (a fact I didn't recognize at first and a good reminder of why this RFC is needed). It would not implement ToBytes and thus cannot be used to cast from. I'll change that</p>



<a name="183157711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183157711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183157711">(Dec 11 2019 at 13:46)</a>:</h4>
<p>This should be a correct version: <a href="https://godbolt.org/z/3fZwMQ" target="_blank" title="https://godbolt.org/z/3fZwMQ">https://godbolt.org/z/3fZwMQ</a> This shows that there is a runtime cost to casting between types that require validation even when the validation is the same between those types and a sufficiently smart compiler could remove those checks.</p>



<a name="183157777"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183157777" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183157777">(Dec 11 2019 at 13:47)</a>:</h4>
<p><span class="user-mention" data-user-id="124289">@rkruppe</span> I will try the per field validation and see what happens.</p>



<a name="183158766"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183158766" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183158766">(Dec 11 2019 at 13:58)</a>:</h4>
<p><span class="user-mention" data-user-id="124289">@rkruppe</span> looks like doing validation per field optimizes away: <a href="https://godbolt.org/z/4uG-mY" target="_blank" title="https://godbolt.org/z/4uG-mY">https://godbolt.org/z/4uG-mY</a></p>



<a name="183158950"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183158950" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183158950">(Dec 11 2019 at 14:00)</a>:</h4>
<p>So far the only runtime cost you seem to pay above what could be written by hand is when two types require validation and they are structurally equal.</p>



<a name="183177754"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183177754" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183177754">(Dec 11 2019 at 17:05)</a>:</h4>
<p>That makes sense and I would expect it to generalize. When the <code>to_bytes</code> + <code>from_bytes</code> pair is fully inlined (necessary for low overhead anyway) then for the <code>from_bytes</code> code all the sizes being compared are constants and the alignment checks are all on constant offsets from the source reference (whose ABI alignment is usually known) and thus amendable to peephole arithmetic simplifications that LLVM is good at.</p>
<p>That just leaves the bitstring validation. I don't think it's realistic to expect that to be optimized away, so <em>if</em> the costs of redundant validation matter then some deeper redesign of the traits is probably required.</p>



<a name="183181425"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183181425" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183181425">(Dec 11 2019 at 17:44)</a>:</h4>
<p>Honestly, I wouldn't have otherwise expected that types with any special bit pattern requirements would be valid<em>at all</em> for using with a safe transmute.</p>
<p>I would also compare this to <code>get_unchecked</code> instead of <code>index</code>. Indexing isn't <em>really</em> free, but you <em>can</em> bypass the safety regulations if you want extra speed in some contexts, and then it's your fault if you do it wrong.</p>



<a name="183183804"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183183804" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183183804">(Dec 11 2019 at 18:08)</a>:</h4>
<p>Is the right thing to do to suggest people model their types different (e.g., booleans as u8), if they don't want runtime checks at all? I think it's a valid question to ask if we should support types that have special validation requirements at all, but it feels like the right thing to do - The performance hit is not so great that it represents a potential performance cliff that people could accidentally run off it.  </p>
<p><span class="user-mention" data-user-id="124289">@rkruppe</span> one thing  I'm not sure about is that in most relevant use cases if the length and alignment will be known. zerocopy has a <a href="https://docs.rs/zerocopy/0.2.8/zerocopy/struct.LayoutVerified.html" target="_blank" title="https://docs.rs/zerocopy/0.2.8/zerocopy/struct.LayoutVerified.html">length and alginment verified slice</a> which allows them to skip those checks once they've been performed. For type to type casting, I believe inlining should always make that obvious to LLVM, but I can imagine some scenarios where it might be harder for rustc/LLVM to know. For instance, when reading from different parts of a buffer. Requiring this makes the API much more complex though...</p>



<a name="183184556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183184556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183184556">(Dec 11 2019 at 18:16)</a>:</h4>
<p>Good point, I was only thinking about the type casting use case. In the general case I don't expect <code>from_bytes</code> with full (size+align+...) validation per field will be optimized so well, since that requires propagating information from branch conditions into the downstream code, which LLVM isn't good at.</p>



<a name="183187047"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183187047" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183187047">(Dec 11 2019 at 18:44)</a>:</h4>
<p>I'll try to make a worse case scenario test case.</p>



<a name="183211918"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183211918" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183211918">(Dec 11 2019 at 23:09)</a>:</h4>
<blockquote>
<p>I don't believe this is an edge case. This also applies to other conversions (e.g., numbers to c-style enums).</p>
</blockquote>
<p>For numbers to C-style enums, though, you usually <em>need</em> a runtime check, just like numbers to bools.  So not optimizing it out wouldn't be a problem.</p>



<a name="183212061"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212061" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212061">(Dec 11 2019 at 23:10)</a>:</h4>
<p>But <span class="user-mention" data-user-id="124289">@rkruppe</span>'s mention of newtypes is more convincing.</p>



<a name="183212119"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212119" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212119">(Dec 11 2019 at 23:11)</a>:</h4>
<p>I'm definitely interested in changing the API to not just be about bytes.</p>



<a name="183212237"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212237" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212237">(Dec 11 2019 at 23:13)</a>:</h4>
<p>To quote myself from the Discourse thread about a possible alternative:</p>
<blockquote>
<div class="codehilite"><pre><span></span><span class="k">trait</span><span class="w"> </span><span class="n">CastSliceTo</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">fn</span> <span class="nf">cast_slice</span><span class="p">(</span><span class="n">slice</span>: <span class="kp">&amp;</span><span class="p">[</span><span class="n">Self</span><span class="p">])</span><span class="w"> </span>-&gt; <span class="nb">Result</span><span class="o">&lt;&amp;</span><span class="p">[</span><span class="n">T</span><span class="p">],</span><span class="w"> </span><span class="n">TransmuteError</span><span class="o">&gt;</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</pre></div>


<p>The name isn't the best, but basically <code>T: FromAnyBytes</code> would be equivalent to <code>u8: CastSliceTo&lt;T&gt;</code>, and <code>T: ToBytes</code> would be equivalent to <code>T: CastSliceTo&lt;u8&gt;</code>.</p>
</blockquote>



<a name="183212257"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212257" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212257">(Dec 11 2019 at 23:13)</a>:</h4>
<p>But really there should probably be infallible and fallible variants.</p>



<a name="183212644"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212644" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212644">(Dec 11 2019 at 23:17)</a>:</h4>
<p>Then you could imagine that a <code>#[repr(transparent)]</code> struct could somehow derive the impls  to infallibly cast between it and its base type.  (Not sure what the syntax would be; it would need to produce two separate impls since the trait would be directional.  It needs to be directional since e.g. it's  safe to cast from [u8] to [Struct] but not vice versa if there's padding.)</p>



<a name="183212830"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183212830" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183212830">(Dec 11 2019 at 23:20)</a>:</h4>
<blockquote>
<p>zerocopy has a <a href="https://docs.rs/zerocopy/0.2.8/zerocopy/struct.LayoutVerified.html" target="_blank" title="https://docs.rs/zerocopy/0.2.8/zerocopy/struct.LayoutVerified.html">length and alginment verified slice</a> which allows them to skip those checks once they've been performed.</p>
</blockquote>
<p>Interesting.  I like this design.</p>



<a name="183228568"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183228568" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183228568">(Dec 12 2019 at 04:45)</a>:</h4>
<p>Regarding the C-style enums: One thing that a friend is demoing into <code>bytemuck</code> (hope to have something to show soon!) is the concept of a "ContiguousEnum", which you often see in both Rust and C. It's some integer values that are all named, with a <code>min..=max</code> range that's valid where all value in that range are used, and all <em>other</em> integer values are simply invalid. In this specific subcase, if you have a raw value you can get it into the enum type with a check that it's in range and then a transmute. You don't have to match on the value with 6 cases or 20 cases or however many (which LLVM will sometimes do right, but usually not handle well).</p>
<p>I think a lot of the transmutations might be of the general form, "how many claims can we make about this type? the most we know the faster we can make the conversion." This might seem obvious of course, but I think that we should keep in mind that something <em>like</em> a specialization mechanism might make a big difference here when the compiler is doing all these generations of conversions. If we can do that it's good because we can jump on a chance to make code faster, but also it can lead to those accidental performance cliffs that Ryan mentioned if it's not obvious to the user that a seemingly small change to a struct (like adding a <code>bool</code>) will silently give them a different derived impl.</p>
<p>Incidentally, is the latest version of any proposal still the discourse thread? Perhaps we should open an issue or PR or similar in the new repo now that it's created.</p>



<a name="183258463"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183258463" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183258463">(Dec 12 2019 at 13:32)</a>:</h4>
<blockquote>
<p>For numbers to C-style enums, though, you usually need a runtime check, just like numbers to bools. So not optimizing it out wouldn't be a problem.</p>
</blockquote>
<p>A runtime check is not needed when converting between two types that require validation where both types only have values that are valid for the other type. For instance between <code>bool</code> and <code>#[repr(u8)] enum Foo { Bar, Baz }</code> . Rust is not capable of eliminating that unnecessary runtime check.</p>



<a name="183258827"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183258827" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183258827">(Dec 12 2019 at 13:37)</a>:</h4>
<blockquote>
<p>To quote myself from the Discourse thread about a possible alternative:</p>
<blockquote>
<div class="codehilite"><pre><span></span><span class="k">trait</span><span class="w"> </span><span class="n">CastSliceTo</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">fn</span> <span class="nf">cast_slice</span><span class="p">(</span><span class="n">slice</span>: <span class="kp">&amp;</span><span class="p">[</span><span class="n">Self</span><span class="p">])</span><span class="w"> </span>-&gt; <span class="nb">Result</span><span class="o">&lt;&amp;</span><span class="p">[</span><span class="n">T</span><span class="p">],</span><span class="w"> </span><span class="n">TransmuteError</span><span class="o">&gt;</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</pre></div>


</blockquote>
</blockquote>
<p>How would you represent <code>&amp;mut [Self]</code> to <code>&amp;mut [T]</code> conversions?</p>
<p>Also, this proposal requires all pairs of convertible types to be matched together. That requires a lot impls. Would this have a negative impact on compiler performance? <br>
Also, what happens if you want to cast between a type not in your crate and some type in our crate? I don't believe this is possible because of orphan rules.</p>



<a name="183258973"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183258973" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183258973">(Dec 12 2019 at 13:39)</a>:</h4>
<blockquote>
<p>Incidentally, is the latest version of any proposal still the discourse thread? Perhaps we should open an issue or PR or similar in the new repo now that it's created.</p>
</blockquote>
<p>Yes it is, I need to work on updating it a bit with some of the things we've learned since then.</p>



<a name="183265456"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183265456" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183265456">(Dec 12 2019 at 14:47)</a>:</h4>
<p>I'm going to remove safe unions from the initial proposal (though I will mention them as a likely future addition in a follow up RFC). Any objections? cc <span class="user-mention" data-user-id="239881">@Josh Triplett</span></p>



<a name="183270594"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183270594" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183270594">(Dec 12 2019 at 15:38)</a>:</h4>
<p>No objection.</p>



<a name="183270717"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183270717" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183270717">(Dec 12 2019 at 15:39)</a>:</h4>
<p>Also, the discourse thread is not quite the latest, as we have some additional improvements.</p>



<a name="183270846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183270846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183270846">(Dec 12 2019 at 15:40)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> we do have additional improvements but those are only captured in comments, the discourse thread is the latest formal full write up. I'm working on making a new version with the additional improvements.</p>



<a name="183353105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183353105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183353105">(Dec 13 2019 at 12:13)</a>:</h4>
<blockquote>
<p>Also, this proposal requires all pairs of convertible types to be matched together. That requires a lot impls. Would this have a negative impact on compiler performance? </p>
</blockquote>
<p>Yes. I think a constraint on a solution to this problem is not having this issue.</p>



<a name="183353125"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183353125" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183353125">(Dec 13 2019 at 12:13)</a>:</h4>
<p>Alternative proposals like the <code>Compatible&lt;T&gt;</code> RFC do not have this problem.</p>



<a name="183353201"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183353201" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183353201">(Dec 13 2019 at 12:14)</a>:</h4>
<blockquote>
<p>Also, what happens if you want to cast between a type not in your crate and some type in our crate? I don't believe this is possible because of orphan rules.</p>
</blockquote>
<p>I think not having this issue should also be a constrain on the solution.</p>



<a name="183353257"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183353257" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183353257">(Dec 13 2019 at 12:15)</a>:</h4>
<p>Since this is a performance-oriented feature, I think that guaranteed no-runtime overhead should also be a constraint.</p>



<a name="183353354"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183353354" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183353354">(Dec 13 2019 at 12:16)</a>:</h4>
<p>If a runtime over-head is acceptable, then there are arguably many alternatives to solving this problem, some of which do not require any unsafe code or trait impls at all.</p>



<a name="183354116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183354116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183354116">(Dec 13 2019 at 12:28)</a>:</h4>
<blockquote>
<p>Alternative proposals like the <code>Compatible&lt;T&gt;</code> RFC do not have this problem.</p>
</blockquote>
<p><span class="user-mention" data-user-id="132920">@gnzlbg</span> Why would <code>Compatible&lt;T&gt;</code> not have this issue as well? You also need a trait impl for every type pair that can be converted between (i.e., if type the user wants to convert between type <code>A</code> and type <code>B</code> there must be a <code>impl Compatible&lt;B&gt; for A</code>. I would also imagine this quickly gets out of hand. Also, as far as I understand it, it has the same issues with the orphan rule as the other proposal.</p>



<a name="183354745"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183354745" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183354745">(Dec 13 2019 at 12:37)</a>:</h4>
<blockquote>
<p>@gnzlbg Why would Compatible&lt;T&gt; not have this issue as well? </p>
</blockquote>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span>  That's explained in the <code>Compatible&lt;T&gt;</code> RFC: <a href="https://gist.github.com/gnzlbg/4ee5a49cc3053d8d20fddb04bc546000" target="_blank" title="https://gist.github.com/gnzlbg/4ee5a49cc3053d8d20fddb04bc546000">https://gist.github.com/gnzlbg/4ee5a49cc3053d8d20fddb04bc546000</a></p>



<a name="183354762"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183354762" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183354762">(Dec 13 2019 at 12:37)</a>:</h4>
<blockquote>
<p>A trait bound of the form T: Compatible&lt;U&gt; is "satisfied" iff given any T: Compatible&lt;U0&gt; there is a type sequence [U_0, U_1, ..., U_N] such that for i in range [1, N) the query U_{i}: Compatible&lt;U_{i+1}&gt; is satisfied and there is a impl of Compatible&lt;U&gt; for U_N. Notice that multiple such sequences could exist, but it suffices that one exists for the query to be satisfied.</p>
</blockquote>



<a name="183354951"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183354951" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183354951">(Dec 13 2019 at 12:40)</a>:</h4>
<p>Notice that for <code>Compatible&lt;T&gt;</code> it doesn't matter which conversion sequence is picked since they are all zero-overhead. However, for <code>TryCompatible</code>,  the RFC does not provide this guarantee and requires the user to pick a conversion sequence.</p>



<a name="183355041"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/performance/near/183355041" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> gnzlbg <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/performance.html#183355041">(Dec 13 2019 at 12:41)</a>:</h4>
<p>We could try to be cleverer for <code>TryCompatible</code>, and pick one of the shortest sequences, but I'm wary of doing that.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>